Computerized system and method for classifying payments to health care practitioner and identifying violations

ABSTRACT

Systems, methods, and other embodiments associated with spend monitoring for pharmaceutical and life science concerns are described. In one embodiment, a method includes receiving transaction data describing a payment made to a health care practitioner. A practitioner identifier that uniquely identifies the practitioner and a transaction type identifier that classifies the transaction as one of several predefined transaction types are associated with the transaction data. The method includes storing a spend record that includes the transaction data, the practitioner identifier, and the transaction type identifier in a spend record database.

BACKGROUND

Legislation in several states, and more recently at the federal level,requires life science companies to disclose financial arrangements withhealthcare providers. The premise of the legislation is that there maybe a perceived (or actual) conflict of interest in some of the sharedfinancial interests. The overall goal of the legislators is to bothregulate certain activities of life science companies and requiretransparency for a range of interactions between health care providersand life science companies. For life science companies conductingmultiple transactions with numerous healthcare providers compliance withthese regulations is cumbersome.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of the specification, illustrate various systems, methods, andother embodiments of the disclosure. It will be appreciated that theillustrated element boundaries (e.g., boxes, groups of boxes, or othershapes) in the figures represent one embodiment of the boundaries. Insome embodiments one element may be designed as multiple elements orthat multiple elements may be designed as one element. In someembodiments, an element shown as an internal component of anotherelement may be implemented as an external component and vice versa.Furthermore, elements may not be drawn to scale.

FIG. 1 illustrates one embodiment of a method associated with a spendmonitor.

FIG. 2 illustrates another embodiment of a method associated with aspend monitor.

FIG. 3 illustrates one embodiment of a system associated with a spendmonitor.

FIGS. 4A-4E are screen shots from one embodiment of a system associatedwith a spend monitor.

FIG. 5 illustrates an embodiment of a computing system in which examplesystems and methods, and equivalents, may operate.

DETAILED DESCRIPTION

The Patient Protection and Affordable Health Care Act (H.R. 3590) thatincludes the Physician Payment Sunshine Act (section 6002) (PPSA) wassigned into law in March 2010. These federal laws require that recordsof transaction data be maintained by life science companies and reportedto the Secretary of Health and Human Services. However, the reportingrequirements in several states, such as Vermont, Massachusetts, D.C.,Maine, West Virginia, Minnesota, Nevada, California, are not pre-emptedby the federal laws. Federal and states laws may require differingreporting timelines, frequency, and content for reporting. Therefore,the reporting requirements can become conflated and complicated.

The laws focus on banning or limiting gifts and other financial benefitsoffered to healthcare providers, gift and financial transactionreporting requirements, and adoption of codes of conduct. The federaland state laws are implemented incrementally as individual states passlaws with differing requirements. Additionally, some states haveregulated manufacturer advertising, industry sponsored clinical trials,and basic research. The variety of regulated activities makes itchallenging to collect and summarize transaction data from various datasources.

Previously, administrators manually located payments to health carepractitioners (HCPs) and enter transaction data for each payment. Thepayment location and data entry may be outsourced to external serviceproviders. However, this manual recordation approach merely recordedpayments in chronological or other arbitrary fashion. Thus, thetransaction data did not offer the ability to view spending per HCP, bypayment type, to identify suspect payments. The manual recordation didnot provide integration across the lines of business, and was expensiveif outsourced. Systems and methods are described herein that providesystematic integration to achieve spending reporting compliance in thelife sciences, pharmaceutical, and medical fields.

With reference to FIG. 1, one embodiment of a method 100 is associatedwith compliance spend monitor is illustrated. The method 100 isperformed in a web service application used for managing transactiondata for life science companies such as pharmaceutical, medical device,biological, and medical supply manufacturers. Web-based protocolhandlers allow web-based applications to operate online allowingtransaction data to be harvested from any number of external sources inreal-time. Furthermore, the transaction data can be integrated andanalyzed.

At 110, transaction data regarding payments made by a life sciencecompany to an HCP is received. Transaction data includes informationabout the amount of a payment to an HCP, the date on which the paymentwas made, the form of payment, and the nature of the payment (e.g.,notes regarding consulting fees, compensation for non-consultingservices, honoraria, gifts, entertainment, food, travel, education,research, charitable contributions, royalties or licenses, current orprospective ownership or investment interests, direct compensation forserving as faculty or as a speaker for a medical education program, andgrants). The transaction data may also includes payments made to anon-HCP on behalf of an HCP. For example, a limo company may be paid toprovide transportation to an HCP on behalf of the life science company.

The transaction data is captured, at 110, by accessing a number of datasources from the life science company. The transaction data may beretrieved automatically (e.g., according to a schedule) or uponoccurrence of a triggering event, such as payment of an invoice forservices rendered or reimbursement of an expense report that includeslunch with an HCP. Alternatively, the sources may be configured to sendtransaction data when the transactions data is generated.

Example transaction data sources, which may be accessed via a web-basedprotocol, include accounts payable processing systems, invoicing systems(e.g., to detect payments to non-HCPs on behalf of an HCP), expensereport processing systems, and other human resources or financialsystems. In one embodiment, the collection of transaction data isperformed, via web, without impacting the normal operation of thefinancial systems at the life science company. Transaction data iscaptured and parsed to determine if it includes a reference to an HCP.Transaction data that references an HCP or other predetermined triggerterm(s) is captured.

If an HCP is referenced in the transaction data, at 120, practitionerand transaction type identifiers are associated with the transactiondata to facilitate compliance with reporting requirements. Thepractitioner identifier uniquely identifies the practitioner. In oneembodiment, a practitioner data source, such as a medical personneldirectory or licensing authority, is accessed to retrieve a uniquepractitioner identifier that identifies the HCP who received thepayment. Assigning the practitioner identifier to each transactionfacilitates tracking payments made to the same HCP, as may be requiredby various regulations. Further, more detailed information may beretrieved from the practitioner data source about an HCP to augment datarecorded in the transaction data. For example, information about anHCP's medical group, business address, or any other information thatfacilitates compliance with reporting requirements may be retrieved fromthe practitioner data source so that it need not be included intransaction data. If more than one practitioner identifier is mapped topractitioner information in the transaction (e.g., two doctors havingthe same name), an interface may be provided to allow manual selectionof the appropriate practitioner based on address or other information.

The transaction type identifier classifies the transaction as one ofseveral predefined transaction types. This classification may beperformed automatically by identifying a transaction type related term(e.g., speaker fee, speech, talk, presentation) in the transaction dataand retrieving a transaction type identifier (e.g., speaker fee) that ismapped to the term. The selection of practitioner identifiers and/ortransaction type identifiers may be performed automatically usingsemantic analysis or manually through a series of screens and promptsthat are provided to allow a data entry technician to rationalize theraw transaction data. As the types of transactions that are regulatedincrease, additional terms may be mapped to new transaction types,making the method readily adaptable.

At 130, the method includes storing a spend record that includes thetransaction data, the practitioner identifier, and the transaction typeidentifier in a spend record database. At 140, the method includesapplying one or more compliance rules to spend records in the spendrecord database. The compliance rules may be retrieved from a compliancerule data source, such as a regulating body. In this manner, most recentversions of compliance rules can be used, and responsibility for keepingthe rules up to date is maintained by the regulating body or otherspecialized organization, rather than the life science company. Thecompliance rules may specify, for example, a limit on total payments toa given HCP over a certain period, a limit on total payments for acertain type of transaction, or a limit on any single payment to an HCP.Compliance rules may vary from state to state, so a user may be promptedto select appropriate compliance rules for application to theirtransaction data.

At 150, the method includes compiling a compliance report thatsummarizes results of the application of the compliance rules to thespend records in the spend record database. The compliance report mayinclude a series of compliance queries that correspond to variouscompliance rules. For example, a query that checks a compliance rulethat limits a total monetary amount paid to a given HCP could aggregatepayments on a per HCP basis and return the practitioner identifier forany practitioners that have been paid more than is allowed. The resultsreturned by the series of compliance queries may be used to populatefields of the compliance report. Retrieval and application of thecompliance rules may be performed by the spend monitor service as wellas transmitting the compliance report to regulatory agencies.

FIG. 2 illustrates one embodiment of a method 200 associated with aspend monitor. The method includes, at 210, receiving transaction datadescribing a payment made to a health care practitioner. The transactiondata specifies a monetary amount paid to the health care practitioner.The method includes, at 220, associating a practitioner identifier withthe transaction data. At 230, the payment is classified by associating atransaction type identifier with the transaction data. At 240, themethod includes storing a spend record comprising the transaction data,the practitioner identifier; and the transaction type identifier in aspend record database. At 250, the method includes providing aninterface for processing queries on the stored spend records.

The spend record database that stores the spend records may bephysically located in a remote database (with respect to the lifescience company) and made accessible via the web. In one embodiment, aspend monitor service may perform the method 200 and access the lifescience company's transaction data, rationalize the data by appendingthe practitioner and transaction type identifiers, and store the data ina database that can be accessed by the life science company by web.

With reference to FIG. 3, one embodiment of a system 300 is associatedwith a spend monitor is illustrated. The system includes a capture logic310 configured to receive transaction data describing a payment made toa health care practitioner. The system 300 also includes a data logic320 configured to rationalize the transaction data received by thecapture logic 310 and transform the transaction data into a formatsuitable for compliance analysis. The data logic 320 includes an HCPlogic 330 configured to associate a practitioner identifier with thetransaction data to create a spend record and to store the spend recordin a spend record database 390. In one embodiment, an HCP data source,such as a medical personnel directory or licensing authority, isaccessed to retrieve a unique practitioner identifier that identifiesthe HCP who received the payment.

The data logic 320 includes a transaction classification logic 340configured to classify the payment by associating a transaction typeidentifier with the transaction data. The transaction classificationlogic 340 may access a classification rule source that stores rules formapping a preferred transaction type identifier to one or more commonlyused transaction terms that may be found in the transaction data. Theclassification rule source may store transaction type identifiers thatare used in compliance reporting. Thus, the same classification rulesource may be used to provide common transaction type identifiers fortransaction data from more than one life science company. Theclassification rule source may be updated as needed when preferred termschange.

The data logic 320 includes a record verification logic 350 that isconfigured to confirm that selected fields of each spend record containacceptable values. The record verification logic 350 applies one or morespend record rules to the spend record and may also provide an interfaceto receive manual edits to the spend record when the spend record doesnot conform to the spend record rules. The record verification logic 350ensures that only “clean” spend records (e.g., complete records withvalid practitioner identifiers and transaction type identifiers) arestored in the spend record database 390. This record verificationfunction greatly improves the accuracy of spend reporting and complianceanalysis. In addition, the record verification logic may apply one ormore transaction rules to the stored spend records and flag spendrecords that violate a transaction rule. An example transaction rule maybe a limit on a payment made in a single transaction. Any payment overthe limit may be flagged for approval by an authorized person.

The system includes an interface logic 360 configured to provide aninterface for processing queries on stored spend records. The interfacelogic includes a dashboard logic 370 configured to perform predeterminedqueries on the stored spend records and to display results to thequeries in a predetermined format. If the spend record database 390includes materialized views, the dashboard logic 370 may be configuredto access the materialized views to populate fields on the dashboarddisplay. The interface logic 360 also includes a remediation logic 375that identifies the payments that do not meet the compliance rules. Theremediation logic 375 may provide an interface for selecting one or moreremediation actions to be performed to address compliance ruleviolations (e.g., reporting the violation to the proper regulating body,review of the violation by an authorized person, and so on).

The computing system 300 also includes a compliance logic 380 configuredto access a compliance rule data source to retrieve one or morecompliance rules and apply the one or more compliance rules to the spendrecords. The compliance logic 380 may also be configured to compile acompliance report that summarizes results of the application of thecompliance rules to the spend records in the spend record database 390.

The spend record database 390 may be structured according to apredetermined schema that is well suited for processing the dashboardand/or compliance queries. A data mart that includes materialized viewsfor spending over various aggregation periods may be included in thespend record database 390.

FIGS. 4A-4E illustrate example screenshots that may be provided by aninterface logic associated with one embodiment of a spend monitor. FIG.4A shows an HCP management screen 400 that includes an HCP descriptionsection 405 that includes fields for storing identifying information fora given HCP. A spend history portion 410 lists payments made to the HCPdescribed in section 405. A remaining amount of payments that may bemade to the HCP within regulation limits is also displayed on the HCPmanagement screen 400.

A spend transaction screen 420 is shown in FIG. 4B. The spendtransaction screen provides a list 425 of all spend records. The list ofspend records may be sorted on any selected attribute. FIG. 4C shows acertification screen 440. The certification screen 440 includes a stateselection portion 445 that displays states for which compliance rulesare stored by the system. Status information about a selected state'scompliance report is shown in a status section 450. FIG. 4D illustratesan approval screen 460. The approval screen 460 includes a stateselection portion 465 that displays states for which compliance rulesare stored by the system. An approval section 470 shows an approvalchain for a selected state's compliance report and indicates whichapprovals have been made and which are still pending.

FIG. 4E shows an analysis screen 480 that illustrates a dashboard thatshows a several types of analysis that can be performed on the spendrecords. A pie chart 484 shows overall spending broken out by state. Abar graph 488 shows spending broken out by state and transaction type.Another bar graph 494 shows a comparison of spending on varioustransaction types. A bar graph 498 shows total spending for eachtransaction type as well as an amount of each transaction type that isspent on a state by state basis.

FIG. 5 illustrates an example computing device in which example systemsand methods described herein, and equivalents, may operate. The examplecomputing device may be a computer 500 that includes a processor 502, amemory 504, and input/output ports 510 operably connected by a bus 508.In one example, the computer 500 may include a spend monitor logic 530configured to monitor payments to HCPs and create spend records forstorage in a spend record database. In different examples, the spendmonitor logic 530 may be implemented in hardware, a non-transitorycomputer-readable medium with stored instructions, firmware, and/orcombinations thereof. While the spend monitor logic 530 is illustratedas a hardware component attached to the bus 508, it is to be appreciatedthat in one example, the spend monitor logic 530 could be implemented inthe processor 502.

In one embodiment, spend monitor logic 530 is a means (e.g., hardware,non-transitory computer-readable medium, firmware) for performing spendmonitoring. The means may be implemented, for example, as an ASICprogrammed to perform spend monitoring. The means may also beimplemented as stored computer executable instructions that arepresented to computer 500 as data 516 that are temporarily stored inmemory 504 and then executed by processor 502.

Generally describing an example configuration of the computer 500, theprocessor 502 may be a variety of various processors including dualmicroprocessor and other multi-processor architectures. A memory 504 mayinclude volatile memory and/or non-volatile memory. Non-volatile memorymay include, for example, ROM, PROM, and so on. Volatile memory mayinclude, for example, RAM, SRAM, DRAM, and so on.

A disk 506 may be operably connected to the computer 500 via, forexample, an input/output interface (e.g., card, device) 518 and aninput/output port 510. The disk 506 may be, for example, a magnetic diskdrive, a solid state disk drive, a floppy disk drive, a tape drive, aZip drive, a flash memory card, a memory stick, and so on. Furthermore,the disk 506 may be a CD-ROM drive, a CD-R drive, a CD-RW drive, a DVDROM, and so on. The memory 504 can store a process 514 and/or a data516, for example. The disk 506 and/or the memory 504 can store anoperating system that controls and allocates resources of the computer500.

The bus 508 may be a single internal bus interconnect architectureand/or other bus or mesh architectures. While a single bus isillustrated, it is to be appreciated that the computer 500 maycommunicate with various devices, logics, and peripherals using otherbusses (e.g., PCIE, 1394, USB, Ethernet). The bus 508 can be typesincluding, for example, a memory bus, a memory controller, a peripheralbus, an external bus, a crossbar switch, and/or a local bus.

The computer 500 may interact with input/output devices via the i/ointerfaces 518 and the input/output ports 510. Input/output devices maybe, for example, a keyboard, a microphone, a pointing and selectiondevice, cameras, video cards, displays, the disk 506, the networkdevices 520, and so on. The input/output ports 510 may include, forexample, serial ports, parallel ports, and USB ports.

The computer 500 can operate in a network environment and thus may beconnected to the network devices 520 via the i/o interfaces 518, and/orthe i/o ports 510. Through the network devices 520, the computer 500 mayinteract with a network. Through the network, the computer 500 may belogically connected to remote computers. Networks with which thecomputer 500 may interact include, but are not limited to, a LAN, a WAN,and other networks.

In another embodiment, the described methods and/or their equivalentsmay be implemented with computer executable instructions. Thus, in oneembodiment, a non-transitory computer-readable medium is configured withstored computer executable instructions that when executed by a machine(e.g., processor, computer, and so on) cause the machine (and/orassociated components) to perform the methods of FIGS. 1 and 2 and toproduce the screen shots of FIGS. 4A-4E.

While for purposes of simplicity of explanation, the illustratedmethodologies in the figures are shown and described as a series ofblocks, it is to be appreciated that the methodologies are not limitedby the order of the blocks, as some blocks can occur in different ordersand/or concurrently with other blocks from that shown and described.Moreover, less than all the illustrated blocks may be used to implementan example methodology. Blocks may be combined or separated intomultiple components. Furthermore, additional and/or alternativemethodologies can employ additional blocks that are not illustrated.

The following includes definitions of selected terms employed herein.The definitions include various examples and/or forms of components thatfall within the scope of a term and that may be used for implementation.The examples are not intended to be limiting. Both singular and pluralforms of terms may be within the definitions.

References to “one embodiment”, “an embodiment”, “one example”, “anexample”, and so on, indicate that the embodiment(s) or example(s) sodescribed may include a particular feature, structure, characteristic,property, element, or limitation, but that not every embodiment orexample necessarily includes that particular feature, structure,characteristic, property, element or limitation. Furthermore, repeateduse of the phrase “in one embodiment” does not necessarily refer to thesame embodiment, though it may.

ASIC: application specific integrated circuit.

CD: compact disk.

CD-R: CD recordable.

CD-RW: CD rewriteable.

DVD: digital versatile disk and/or digital video disk.

HTTP: hypertext transfer protocol.

LAN: local area network.

PCI: peripheral component interconnect.

PCIE: PCI express.

RAM: random access memory.

DRAM: dynamic RAM.

SRAM: synchronous RAM.

ROM: read only memory.

PROM: programmable ROM.

EPROM: erasable PROM.

EEPROM: electrically erasable PROM.

SQL: structured query language.

OQL: object query language.

USB: universal serial bus.

XML: extensible markup language.

WAN: wide area network.

“Computer component”, as used herein, refers to a computer-relatedentity (e.g., hardware, firmware, instructions in execution,combinations thereof). Computer components may include, for example, aprocess running on a processor, a processor, an object, an executable, athread of execution, and a computer. A computer component(s) may residewithin a process and/or thread. A computer component may be localized onone computer and/or may be distributed between multiple computers.

“Computer communication”, as used herein, refers to a communicationbetween computing devices (e.g., computer, personal digital assistant,cellular telephone) and can be, for example, a network transfer, a filetransfer, an applet transfer, an email, an HTTP transfer, and so on. Acomputer communication can occur across, for example, a wireless system(e.g., IEEE 802.11), an Ethernet system (e.g., IEEE 802.3), a token ringsystem (e.g., IEEE 802.5), a LAN, a WAN, a point-to-point system, acircuit switching system, a packet switching system, and so on.

“Computer-readable medium”, as used herein, refers to a non-transitorymedium that stores instructions and/or data. A computer-readable mediummay take forms, including, but not limited to, non-volatile media, andvolatile media. Non-volatile media may include, for example, opticaldisks, magnetic disks, and so on. Volatile media may include, forexample, semiconductor memories, dynamic memory, and so on. Common formsof a computer-readable medium may include, but are not limited to, afloppy disk, a flexible disk, a hard disk, a magnetic tape, othermagnetic medium, an ASIC, a CD, other optical medium, a RAM, a ROM, amemory chip or card, a memory stick, and other media from which acomputer, a processor or other electronic device can read.

In some examples, “database” is used to refer to a table. In otherexamples, “database” may be used to refer to a set of tables. In stillother examples, “database” may refer to a set of data stores and methodsfor accessing and/or manipulating those data stores.

“Logic”, as used herein, includes but is not limited to hardware,firmware, a non-transitory computer readable medium that storesinstructions, instructions in execution on a machine, and/orcombinations of each to perform a function(s) or an action(s), and/or tocause a function or action from another logic, method, and/or system.Logic may include a microprocessor controlled by an algorithm, adiscrete logic (e.g., ASIC), an analog circuit, a digital circuit, aprogrammed logic device, a memory device containing instructions, and soon. Logic may include one or more gates, combinations of gates, or othercircuit components. Where multiple logics are described, it may bepossible to incorporate the multiple logics into one physical logic.Similarly, where a single logic is described, it may be possible todistribute that single logic between multiple physical logics.

An “operable connection”, or a connection by which entities are“operably connected”, is one in which signals, physical communications,and/or logical communications may be sent and/or received. An operableconnection may include a physical interface, an electrical interface,and/or a data interface. An operable connection may include differingcombinations of interfaces and/or connections sufficient to allowoperable control. For example, two entities can be operably connected tocommunicate signals to each other directly or through one or moreintermediate entities (e.g., processor, operating system, logic,non-transitory computer-readable medium). Logical and/or physicalcommunication channels can be used to create an operable connection.

“Query”, as used herein, refers to a semantic construction thatfacilitates gathering and processing information. A query may beformulated in a database query language (e.g., SQL), an OQL, a naturallanguage, and so on.

“User”, as used herein, includes but is not limited to one or morepersons, computers or other devices, or combinations of these.

While example systems, methods, and so on have been illustrated bydescribing examples, and while the examples have been described inconsiderable detail, it is not the intention of the applicants torestrict or in any way limit the scope of the appended claims to suchdetail. It is, of course, not possible to describe every conceivablecombination of components or methodologies for purposes of describingthe systems, methods, and so on described herein. Therefore, thedisclosure is not limited to the specific details, the representativeapparatus, and illustrative examples shown and described. Thus, thisapplication is intended to embrace alterations, modifications, andvariations that fall within the scope of the appended claims.

To the extent that the term “includes” or “including” is employed in thedetailed description or the claims, it is intended to be inclusive in amanner similar to the term “comprising” as that term is interpreted whenemployed as a transitional word in a claim.

To the extent that the term “or” is used in the detailed description orclaims (e.g., A or B) it is intended to mean “A or B or both”. When theapplicants intend to indicate “only A or B but not both” then the phrase“only A or B but not both” will be used. Thus, use of the term “or”herein is the inclusive, and not the exclusive use. See, Bryan A.Garner, A Dictionary of Modern Legal Usage 624 (2d. Ed. 1995).

To the extent that the phrase “one or more of, A, B, and C” is usedherein, (e.g., a data store configured to store one or more of, A, B,and C) it is intended to convey the set of possibilities A, B, C, AB,AC, BC, and/or ABC (e.g., the data store may store only A, only B, onlyC, A&B, A&C, B&C, and/or A&B&C). It is not intended to require one of A,one of B, and one of C. When the applicants intend to indicate “at leastone of A, at least one of B, and at least one of C”, then the phrasing“at least one of A, at least one of B, and at least one of C” will beused.

What is claimed is:
 1. A non-transitory computer-readable medium storingcomputer-executable instructions that when executed by at least aprocessor of a computer cause the computer to: access, via an internetconnection, one or more data sources maintained by a company andretrieve transaction data that includes data of payments made by thecompany, wherein the transaction data is described by terms; parse, byat least the processor, the transaction data to identify terms thatreference a health care practitioner and to identify one or moremonetary amounts paid to the health care practitioner; classify, by atleast the processor, the one or more monetary amounts paid to the healthcare practitioner from the transaction data by identifying transactiontype from the terms in the transaction data, and retrieving atransaction type identifier that is mapped to the term, where thetransaction type identifier classifies the term as one of severaldifferent types of monetary payments including gift payments, whereinthe transaction type identifier is determined by comparing the term ofthe monetary amount to a set of stored predefined transaction types;identify, by at least the processor accessing a practitioner datasource, a practitioner identifier that uniquely identifies the healthcare practitioner; create and store, by at least the processor, a spendrecord in a spend record database, where the spend record includes datacorresponding to: the transaction data, the practitioner identifier, andthe transaction type identifier, where creating a spend record thatincludes the practitioner identifier and the transaction type identifierin the spend record facilitates web-based querying of spend recordsstored in the spend record database by a provider of the transactiondata based, at least in part, on the practitioner identifier oftransaction type identifier; access, by at least the processor, acompliance rule data source that includes one or more compliance rulesthat specify limits on at least gift payments made to the health carepractitioner; query, by at least the processor, the compliance rule datasource to identify a compliance rule associated with the transactiontype that specifies a limit on monetary amounts that include giftpayments paid to the health care practitioner for transactions of thetransaction type; query, by at least the processor, the spend recorddatabase to aggregate the monetary amounts in the spend records for eachof the practitioner identifiers based on the transaction type identifierto generate a resulting aggregated monetary amount made to the healthcare practitioner for gift payments; compare, by at least the processor,the resulting aggregated monetary amount for each of the practitioneridentifiers with the limit on the monetary amounts that include giftpayments; and compile, by at least the processor, a compliance reportthat reports a result of the comparison to identify the health carepractitioners that have the aggregated monetary amount that is more thanthe limit on the monetary amounts that include gift payments, andgenerate a flag to indicate a violation for the associated spend record.2. The non-transitory computer-readable medium of claim 1, wherein theinstructions that cause the computer to retrieve the transaction datacomprises instructions for causing the computer to retrieve a paymentrecord from a financial transaction processing system.
 3. Thenon-transitory computer-readable medium of claim 1, where theinstructions further comprise providing an interface for selecting oneor more remediation actions when the aggregated monetary amount exceedsthe limit on the monetary amounts.
 4. The non-transitorycomputer-readable medium of claim 1, where the instructions furthercomprise instructions that cause the computer to transmit the compliancereport to an external compliance authority.
 5. The non-transitorycomputer-readable medium of claim 1, where the instructions furthercomprise instructions for causing the computer to generate an interfaceto receive and process queries on the spend records.
 6. A computingsystem, comprising: a processor; capture logic stored in anon-transitory computer readable medium that includes executableinstructions executable by the processor and configured to cause theprocessor to: access, via an internet connection, one or more datasources maintained by a company, and retrieve transaction data thatincludes data of payments made by the company, wherein the transactiondata is described by terms; parse, by at least the processor, thetransaction data to identify terms that reference a health carepractitioner and to identify one or more monetary amounts paid to thehealth care practitioner; data logic stored in a non-transitory computerreadable medium that includes executable instructions executable by theprocessor and configured to cause the processor to: classify, by atleast the processor, the one or more monetary amounts paid to the healthcare practitioner from the transaction data by identifying a transactiontype from the terms in the transaction data, and retrieving atransaction type identifier that is mapped to the term, where thetransaction type identifier classifies the term as one of severaldifferent types of monetary payments including gift payments, whereinthe transaction type identifier is determined by comparing the term ofthe monetary amount to a set of stored predefined transaction types;identify, by at least the processor accessing a practitioner datasource, a practitioner identifier that uniquely identifies the healthcare practitioner; create and store, by at least the processor, a spendrecord in a spend record database, where the spend record includes datacorresponding to: the transaction data, the practitioner identifier, andthe transaction type identifier, where creating a spend record thatincludes the practitioner identifier and the transaction type identifierin the spend record facilitates web-based querying of spend recordsstored in the spend record database by a provider of the transactiondata based, at least in part, on the practitioner identifier oftransaction type identifier; compliance logic stored in a non-transitorycomputer readable medium that includes executable instructionsexecutable by the processor and configured to cause the processor to:access, by at least the processor, a compliance rule data source thatincludes one or more compliance rules that specify limits on at leastgift payments made to the health care practitioner; query, by at leastthe processor, the compliance rule data source to identify a compliancerule associated with the transaction type that specifies a limit onmonetary amounts that include gift payments paid to the health carepractitioner for transactions of the transaction type; query, by atleast the processor, the spend record database to aggregate the monetaryamounts in the spend records for each of the practitioner identifiersbased on the transaction type identifier to generate a resultingaggregated monetary amount made to the health care practitioner for giftpayments; compare, by at least the processor, the resulting aggregatedmonetary amount for each of the practitioner identifiers with the limiton the monetary amounts that include gift payments; and compile, by atleast the processor, a compliance report that reports a result of thecomparison to identify the health care practitioners that have theaggregated monetary amount that is more than the limit on the monetaryamounts that include gift payments, and generate a flag to indicate aviolation for the associated spend record.
 7. The computing system ofclaim 6, further comprising an interface logic stored in a memory in thecomputing system, wherein the interface logic includes instructionsexecutable by the processor and configured to cause the processor togenerate an interface for processing queries on stored spend records anddisplaying results of the comparison on a display screen of thecomputing system; and where the interface logic further comprises adashboard logic configured to cause the processor to performpredetermined queries on the stored spend records and to display resultsto the queries in a predetermined format.
 8. The computing system ofclaim 7, where the interface logic further comprises a remediation logicconfigured to cause the processor to provide an interface for selectingone or more remediation actions when the aggregated monetary amountexceeds the limit on monetary amounts.
 9. A computer-implemented methodperformed by a computer system including at least a processor and amemory for executing instructions, the method comprising: accessing, viaan internet connection, one or more data sources maintained by acompany, and retrieve transaction data that includes data of paymentsmade by the company, wherein the transaction data is described by terms;parsing, by at least the processor, the transaction data to identifyterms that reference a health care practitioner and to identify one ormore monetary amounts paid to the health care practitioner; classifying,by at least the processor, the one or more monetary amounts paid to thehealth care practitioner from the transaction data by identifying atransaction type from the terms in the transaction data, and retrievinga transaction type identifier that is mapped to the term, where thetransaction type identifier classifies the term as one of severaldifferent types of monetary payments including gift payments, whereinthe transaction type identifier is determined by comparing the term ofthe monetary amount to a set of stored predefined transaction types;identifying, by at least the processor accessing a practitioner datasource, a practitioner identifier that uniquely identifies the healthcare practitioner; creating and storing, by at least the processor, aspend record in a spend record database, where the spend record includesdata corresponding to: the transaction data, the practitioneridentifier, and the transaction type identifier, where creating a spendrecord that includes the practitioner identifier and the transactiontype identifier in the spend record facilitates web-based querying ofspend records stored in the spend record database by a provider of thetransaction data based, at least in part, on the practitioner identifierof transaction type identifier; accessing, by at least the processor, acompliance rule data source that includes one or more compliance rulesthat specify limits on at least gift payments made to the health carepractitioner; querying, by at least the processor, the compliance ruledata source to identify a compliance rule associated with thetransaction type that specifies a limit on monetary amounts that includegift payments paid to the health care practitioner for transactions ofthe transaction type; querying, by at least the processor, the spendrecord database to aggregate the monetary amounts in the spend recordsfor each of the practitioner identifiers based on the transaction typeidentifier to generate a resulting aggregated monetary amount made tothe health care practitioner for gift payments; comparing, by at leastthe processor, the resulting aggregated monetary amount for each of thepractitioner identifiers with the limit on the monetary amounts thatinclude gift payments; and compiling, by at least the processor, acompliance report that reports a result of the comparison to identifythe health care practitioners that have the aggregated monetary amountthat is more than the limit on the monetary amounts that include giftpayments, and generate a flag to indicate a violation for the associatedspend record.
 10. The computer-implemented method of claim 9, wherereceiving the transaction data comprises receiving a payment record froma financial transaction processing system.
 11. The computer-implementedmethod of claim 9, further comprising providing an interface forselecting one or more remediation actions when the aggregated monetaryamount exceeds the given limit on monetary amounts.
 12. Thecomputer-implemented method of claim 9, further comprising transmittingthe compliance report to an external compliance authority.
 13. Thecomputer-implemented method of claim 9, further comprising providing aninterface to receive and process queries on the spend records.